1. Field of the Invention
The present invention relates to a method and apparatus for use in a communications network, for example a Universal Mobile Telecommunications System having an IP Multimedia Subsystem.
2. Description of the Related Art
IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The UMTS (Universal Mobile Telecommunications System) is a third generation wireless system designed to provide higher data rates and enhanced services to subscribers. UMTS is a successor to the Global System for Mobile Communications (GSM), with an important evolutionary step between GSM and UMTS being the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packets switch transmissions well beyond the 64 kbps limit of ISDN through the GSM call network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. UMTS is standardised by the 3rd Generation Partnership Project (3GPP) which is a conglomeration of regional standards bodies such as the European Telecommunication Standards Institute (ETSI), the Association of Radio Industry Businesses (ARIB) and others. See 3GPP TS 23.002 for more details.
The UMTS architecture includes a subsystem known as the IP Multimedia Subsystem (IMS) for supporting traditional telephony as well as new IP multimedia services (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The 3GPP has chosen SIP for signalling between a User Equipment (UE) and the IMS as well as between the components within the IMS.
Specific details of the operation of the UMTS communications network and of the various components within such a network can be found from the Technical Specifications for UMTS that are available from http://www.3gpp.org. Further details of the use of SIP within UMTS can be found from the 3GPP Technical Specification TS 24.228 V5.8.0 (2004-03).
FIG. 1 of the accompanying drawings illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
A user registers with the IMS using the specified SIP REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates a S-CSCF to that user from the set of available S-CSCFs. Whilst the criteria for allocating S-CSCFs is not specified by 3GPP, these may include load sharing and service requirements. It is noted that the allocation of an S-CSCF is key to controlling (and charging for) user access to IMS-based services. Operators may provide a mechanism for preventing direct user-to-user SIP sessions which would otherwise bypass the S-CSCF.
During the registration process, it is the responsibility of the I-CSCF to select an S-CSCF if a S-CSCF is not already selected. The I-CSCF receives the required S-CSCF capabilities from the home network's Home Subscriber Server (HSS), and selects an appropriate S-CSCF based on the received capabilities. [It is noted that S-CSCF allocation is also carried out for a user by the I-CSCF in the case where the user is called by another party, and the user is not currently allocated an S-CSCF.] When a registered user subsequently sends a session request to the IMS, the P-CSCF is able to forward the request to the selected S-CSCF based on information received from the S-CSCF during the registration process.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end-users in an IMS system, and may be connected either as end-points over the 3GPP defined Mr interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment. Different IFCs may be applied to different call cases. The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's User Profile. Certain Application Servers will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server). For example, in the case of call forwarding, the appropriate (terminating) application server will determine the new terminating party to which a call to a given subscriber will be forwarded. In the case that an IFC indicates that a SIP message received at the S-CSCF should be forwarded to a particular SIP AS, that AS is added into the message path. Once the SIP message is returned by the AS to the S-CSCF, it is forwarded on towards its final destination, or forwarded to another AS if this is indicated in the IFCs.
According to 3GPP Multimedia standardisation, multimedia signalling and control is carried out always through the user's home network even in the case of a user roaming in another visited network. In this context, “roaming” is concerned with IMS roaming; this is not related with roaming between radio cells, but roaming between IMS Core Network elements. This means that the P-CSCF, the first IMS element contacted by the subscriber, doesn't belong to the IMS home operator of the subscriber (the UMTS or GPRS operator could be the same so there wouldn't be roaming at the radio level).
3GPP defines in Chapter 4.2.3 of [3GPP TS 23.228 V7.4.0 (2006-06) TS Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 6)] how to support roaming users and its implications on service execution for said users. The following text has been extracted from Chapter 4.2.3 of 3GPP TS 23.228 v7.0.0 to illustrate current state of the art:                “The architecture shall be based on the principle that the service control for Home subscribed services for a roaming subscriber is in the Home network, e.g., the Serving-CSCF is located in the Home network.”        
There are two possible scenarios to provide services:                Via the service platform in the Home Network. This is illustrated in FIG. 2 of the accompanying drawings.        Via an external service platform (e.g. third party or visited network). This is illustrated in FIG. 3 of the accompanying drawings.        
The external service platform entity could be located in either the visited network or in the 3rd party platform.
The roles that the CSCF plays are described below.                The Proxy-CSCF shall enable the session control to be passed to the Serving-CSCF.        The Serving-CSCF is located in the home network. The Serving-CSCF shall invoke service logic.        
A Proxy-CSCF shall be supported in both roaming and non-roaming case, even when the Serving-CSCF is located in the same IM CN Subsystem.
Chapter 4.2.4 of 3GPP 23.228 v7.0.0 describes the ISC interface (IP Multimedia Service Control interface) between the S-CSCF and the service platform (e.g. an AS).
An Application Server (AS) offering value added IM services resides either in the user's home network or in a third party location. The third party could be a network or simply a stand-alone AS.
The Serving-CSCF to AS interface is used to provide services residing in an AS. Two cases were identified:                Serving-CSCF to an AS in Home Network.        Serving-CSCF to an AS in External Network (e.g. Third Party or Visited).        
The SIP Application Server may host and execute services. The SIP Application Server can influence and impact the SIP session on behalf of the services and it uses the ISC interface to communicate with the S-CSCF.
The Application Server Subscription Information is the set of all Filter Criteria that are stored within the HSS for service profile for a specific user. Initial Filter Criteria (IFC) are stored in the HSS as part of the user profile and are downloaded to the S-CSCF upon user registration, or upon a terminating initial request for an unregistered user if unavailable. They represent a provisioned subscription of a user to an application. After downloading the User Profile from the HSS, the S-CSCF assesses the filter criteria to determine the need to forward SIP requests to Application Servers. Initial Filter Criteria are valid throughout the registration lifetime of a user or until the User Profile is changed.
An informative example of an IFC is provided in 3GPP 29.228 v6.8.0, and this is extracted and shown in FIG. 4 of the accompanying drawings.
The absence of Trigger Point instance will indicate an unconditional triggering to Application Server.
FIG. 4 shows that an IFC includes both the Application Server that will provide the service and the trigger point (or condition) that will make the service to be executed. As stated before, the Home Operator provisions IFCs and thus all the information belongs to the Home Operator, with the particularity that the Defined Application Server can be a Visited one.
By means of Camel, it is possible to provide mobile users access to home operator services in GSM/GPRS/UMTS. HLR provide Camel Subscription Information (CSI) to the network elements that may trigger a service. Those CSIs include, as in the case if IFC in IMS, the services trigger conditions and the identification of the gsmSCF that will execute the service.
According to [3GPP TS 22.078 v7.4.0 (2005-06) TS Technical Specification Group Services and System Aspects; Customised Applications for Mobile network Enhanced Logic (CAMEL); Service Description; Stage 1 (Release 7)], CAMEL Subscription Information is provided by the HPLMN operator by administrative means (as in the case of IFCs for IMS).
The following reference might also be considered in relation to the above: 3GPP TS 29.328 V6.5.0 (2005-03) TS Group Core Network; IP Multimedia Subsystem (IMS) Sh interface signalling flows and message contents; Release 6.
The applicant has identified several problems with the existing solutions, which will now be outlined.
The current solution considers that Initial Filter Criteria (IFC) are stored as part of a user's profile; the IFC is triggered if a certain condition is fulfilled.
The current solution does not consider IFCs that can be defined for services that affect groups of users, such as users that are in a given a location, without having first included the IFC in the user profiles in the HSS.
The previous implies that IFCs cannot be downloaded dynamically if certain conditions are fulfilled (e.g. user's position allows using a related service, if user is roaming and is allowed to consume local services in a visited network) to a serving entity (S-CSCF).
Regarding roaming in particular, the current solution is built on the basis that service control for Home subscribed services for a roaming subscriber is located in the Home network. Thus, it is the home network that controls the execution of services, which are just defined by the home operator.
Thus, the user is provided with all the possible services he has access to and these ones are controlled by the S-CSCF that is aware of said services at registration time (it may also be aware if there are some changes due to operational procedures).
But in reality it will be quite unlikely that an operator is aware about all the details of a service provided by a second operator or an external domain and this is even more critical when the operator requires the knowledge about the services offered by every operator with a roaming agreement or an agreement with third parties in general.
Consequently, the IMS user in a roaming situation will be able to access in fact only to a reduced set of the local services provided by the visitor operators.
FIG. 5 of the accompanying drawings shows the current situation and the ensuing problems, which are considered to be as follows:                The IFCs in 3GPP IMS are always part of a user profile belonging to a home network and stored in a Home Subscription Server.        Upon registration, all IFCs in a user's profile are downloaded (over the Cx interface) to the allocated S-CSCF as part of the user's profile. IFCs not in the user's profile are not even considered.        Visited Networks may wish to offer local services to roaming users (e.g. special rates, optimal resource allocations, use of local dialling plans, etc). These services need to be triggered by an IFC.        Since these IFCs are offered by a visited network only to roaming users, it is too costly to store them in ALL user profiles in the HSS (for all users in all networks), in case they roam.        The previous considerations are also applicable to IFCs belonging to any external domain in general (not just a visited operator) that is not the user's home operator.        
Hence, at this moment there is no means by which the visited network or an external domain can send (either dynamically or via provisioning) a set of IFCs that apply to any user and are only executed in said case, without associating them to a user profile.
Table 1 below, extracted from 3GPP 23.228 v7.0.0, shows the information that is currently stored both in the HSS and in the S-CSCF before, during and after registration. IFCs that are not part of the user profile stored in the HSS are not considered to date.
TABLE 1BeforeAfterNodeRegistrationDuring RegistrationRegistrationHSSUser ServiceP-CSCF Network IDServing-CSCFProfileaddress/name\Serving-CSCFNo stateHSS Address/nameMay have session(Home)informationUser profilestate Information(limited - as perSame as duringnetwork scenario)registrationProxy address/nameP-CSCF Network IDPublic/Private User IDUE IP Address
In general, this applies to external application servers (external service platforms) that wish to define Initial Filter Criteria that dynamically apply to a user (or set of users) without necessarily including the related IFC as part of the user's profile.
It is desirable to address at least some of the above identified issues.